Today, computing devices are almost always interconnected via networks. These networks can be large closed networks, as within a corporation, or truly public networks, as with the Internet. A network itself might have hundreds, thousands or even millions of potential users. Consequently it is often required to restrict access to any given networked computer or service, or a part of a networked computer or service, to a subset of the users on the public or closed network. For instance, a brokerage might have a public website accessible to all, but would like to only give Ms. Alice Smith access to Ms. Alice Smith's brokerage account.
Access control is an old problem, tracing its roots to the earliest days of computers. Passwords were among the first techniques used, and to this day remain the most widely used, for protecting resources on a computer or service.
Multifactor Password Authentication
Multiple factor authentication exists as a potential solution to the problems inherent with single factor password authentication. In multiple factor password authentication, at least knowledge of, if not actual possession of, two or more factors, at least one of which comes from a password, must be shown for authentication to be complete. It should be understood that in multiple factor password authentication, each factor remains separate. That is, the factors are not combined. Further, the factors are not even concatenated. Several multiple factor authentication techniques exist, including one time password token techniques, password encrypted computer storage techniques, password secured smart card techniques, and split asymmetric key techniques.
—One Time Password Token Techniques—
In one time password token techniques, two passwords are utilized, one typically being a permanent password associated with the user, and the other being a temporary, one-time use, password generated by a password generator. The permanent password may be optional, and two temporary passwords may instead be used. The temporary password has a finite usable life, such as sixty seconds. At the end of the useable life, another temporary password is generated. An authenticating computer knows each usable password as well as its useable life, based upon algorithms well known to those of ordinary skill in the art. A user transmits both the permanent password (first factor) and a temporary password (second factor) to the authenticating computer which then verifies both passwords. If the passwords are transmitted in the clear, these token techniques are subject to man-in-the-middle (MITM) attacks. Often the passwords are transmitted over a SSL protected channel with server-side SSL (also known as one-way SSL) where the server has a certificate but the client does not. This situation is also vulnerable to MITM attacks. Full-fledged client-side SSL (also known as two-way SSL) where both the server and client have certificates is not vulnerable in this manner.
—Split Asymmetric Key Techniques—
With asymmetric key cryptography every user is associated with a private/public crypto-key pair, commonly referred to as d and e, which are related by special mathematical properties. These properties result in the following functionality: a message encrypted with one of the two keys can then only be decrypted with the other.
One of these keys for each user is made public and the other is kept private. Let us denote the former by e, and the latter by d. So Alice knows dalice, and everyone knows ealice. To send Alice the symmetric key K, Bob simply sends ciphertext C=Encrypt(K,ealice). Alice, and only Alice (since no one else knows dalice), can decrypt the ciphertext C to recover the message, i.e. Decrypt(C,dalice)=K. Now both Alice and Bob know K and can use it for encrypting subsequent messages using a symmetric key system. Why not simply encrypt the message itself with the asymmetric system? This is simply because in practice all known asymmetric systems are fairly inefficient, and while they are perfectly useful for encrypting short strings such as K, they are inefficient for large messages.
The above illustrates how asymmetric cryptography can solve the key distribution problem. Asymmetric cryptography can also be used to solve another important problem, that of digital signatures. To sign a message M, Alice encrypts it with her own private key to create S=Encrypt(M,dalice). She can then send (M,S) to the recipient who can then decrypt S with Alice's public key to generate M′, i.e. M′=Decrypt(S,ealice). If M′ M then the recipient has a valid signature as only someone who has dalice, by definition only Alice, can generate S, which can be decrypted with ealice to produce M. To convey the meaning of these cryptographic operations more clearly they are often written as S=Sign(M,dalice) and M′=Verify(S,ealice). It is worth noting that asymmetric key digital signatures provide non-repudiation in addition to the integrity and authentication achieved by symmetric key Message Authentication Codes (MACs). With MACs the verifier can compute the MAC for any message M of his choice, since the computation is based on a shared secret key. With digital signatures this is not possible since only the sender has knowledge of the sender's private key required to compute the signature. The verifier can only verify the signature, but not generate it. It will be recognized by those skilled in this art that there are numerous variations and elaborations of these basic cryptographic operations of symmetric key encryption, symmetric key MACs, asymmetric key encryption and asymmetric key signatures.
The RSA cryptosystem is one system that implements asymmetric cryptography as described above. In particular, the RSA cryptosystem allows the same private-public crypto-key pair to be used for encryption and for digital signatures. It should be noted that there are other asymmetric cryptosystems that implement encryption only e.g., ElGamal, or digital signature only, e.g., DSA. Technically the public key in RSA is a pair of numbers e, N and the private key is the pair of numbers d, N. When N is not relevant to the discussion, it is commonplace to refer only to the public key as e and the private key as d.
Finally, the above description does not answer the important question of how Bob gets Alice's public key ealice. The process for getting and storing the binding [Alice, ealice] which binds ealice to Alice is tricky. The most practical method appears to be to have the binding signed by a common trusted authority. Such a “certificate authority” (CA) can create CERTalice=Sign([Alice, ealice], dca). Now CERTalice can be verified by anyone who knows the CA's public key eca. So in essence, instead of everyone having to know everyone else's public key, everyone only need know a single public key, i.e. that of the CA. More elaborate schemes with multiple Certificate Authorities, sometimes having a hierarchical relationship, have also been proposed.
Asymmetric key cryptosystems have been around for a long time, but have found limited use. The primary reasons are twofold: (a) the private key d in most systems is long, which means that users cannot remember them, and they have to either be stored on every terminal a user uses, or carried around on smart cards or other media; and (b) the infrastructure for ensuring a certificate is valid, which is critical, is cumbersome to build, operate, and use. The first technique proposed to validate certificates was to send every recipient a list of all certificates that had been revoked. This clearly does not scale well to an environment with millions of users. A later technique proposed to validate certificates was to require that one inquire about the validity of a certificate on-line, which has its own associated problems.
—Split Asymmetric Key Cryptography—
A system based on split asymmetric key cryptography has been developed to solve these two issues, i.e. long private keys and certificate validity, among others. In this system the private key for Alice, i.e. dalice, is further split into two parts, a part daa which Alice knows, and a part das which is stored at a security server, where daa*das=dalicemodφ(N). To sign a message, Alice could perform a partial encryption to generate a partial signature, i.e. PS=Sign(M,daa). Alice then sends the server PS which ‘completes’ the signature by performing S=Sign(PS,das). This completed signature S is indistinguishable from one generated by the original private key, i.e. dalice, so the rest of the process works as previously described. However, daa can be made short, which allows the user to remember it as a password, so this system is user friendly. Further, if the server is informed that a particular ID has been suspended or revoked, then it will cease to perform its part of the operation for that user, and consequently no further signatures can ever be performed. This provides for instant revocation in a simple, highly effective fashion. It will be recognized by those skilled in the art that a split private key can be used in a similar manner for decryption purposes, and that the partial signatures (or encryptions) may be performed in the reverse sequence, that is first by the security server and subsequently by the user's computer, or may even be performed concurrently in both places and then combined.
Authentication Using Split Key Asymmetric Cryptography and the Secure Socket Layer (SSL)
Let us return now to password based systems. Challenge-response systems solve the issue of having to send passwords in the clear across a network. If the authenticating computer and Alice share a secret password, P, then the authenticating computer can send her a new random challenge, R, at the time of login. Alice computes C=Encrypt(R,P) and sends back C. The authenticating computer computes Decrypt(C,P)=C′. If C=C′, then the authenticating computer can trust that it is Alice at the other end. Note however that the authenticating computer had to store P.
A more elegant solution can be created using asymmetric cryptography. Now Alice has a private key dalice, or in a split private key system she has daa. The authenticating computer challenges her to sign a new random challenge R. She signs the challenge, or in the split private key system she interacts with the security server to create the signature, and sends it back to the authenticating computer which uses her public key, retrieved from a certificate, to verify the signature. Observe that the authenticating computer does not have to know her private key, and that an eavesdropper observing the signature on R gains no knowledge of her private key.
—Server Side SSL—
The secure socket layer (SSL) system, which is widely used on the Internet, in effect implements a more elaborate version of exactly this protocol. SSL has two components, ‘server side SSL’ in which a server proves its identity by correctly decrypting a particular message during connection set-up. As browsers, such as Netscape and Microsoft Internet Explorer, come loaded with the public keys of various CAs, the browser can verify the certificate of the server and use the public key therein for encryption. This authenticates the server to the client, and also allows for the set-up of a session key K, which is used to encrypt and MAC all further communications. Server side SSL is widely used, as the complexity of managing certificates rests with system administrators of web sites who have the technical knowledge to perform this function.
—Client Side SSL—
The converse function in SSL, client side SSL, which lets a client authenticate herself to a server by means of a digital signature, is rarely used. This is because although the technical mechanism is much the same, it now requires users to manage certificates and, unless they use a split private key, long private keys, which has proven to be difficult. So in practice, most Internet web sites use server side SSL to authenticate themselves to the client, and to obtain a secure channel, and from then on use Userid, Password pairs to authenticate the client.
So far from disappearing, the use of passwords has increased dramatically. Passwords themselves are often dubbed as inherently “weak”. This is inaccurate because, if they are used carefully, passwords can actually achieve “strong” security. As discussed above, passwords should not be sent over networks, and if possible should not be stored on the receiving computer. Instead, in a “strong” system, the user can be asked to prove knowledge of the password without actually revealing the password. Perhaps most critical is that passwords should not be vulnerable to dictionary attacks.
Vulnerability of Passwords to Phishing by Impostor Website and Man-in-the-Middle (MITM) Attacks
As noted above, users are often required to submit their user IDs and passwords as credentials to a website, in order to authenticate themselves to the website. In such cases, an attacker who gains access to a user ID and associated password, can impersonate the user from the attacker's or any other terminal.
—Impostor Website Attacks—
In practice users often have no absolute guarantee that the website to which they submit these credentials, is in-fact the website with which the user intends to communicate. This is because, while the website might look and feel like the intended website, e.g. the website of an Internet Service Provider (ISP) or some well-known e-commerce website such as an on-line bank or merchant, it could in-fact actually be an imposter website which has been set-up by an attacker to have the look and feel of the real website of the entity with whom the user wishes to communicate. This type of attack is commonly referred to as a form of “phishing”.
If a user submits her credentials to the imposter website, an attacker could then use the submitted credentials to gain access to the user's confidential information and take advantage of the user's relationship with the real website and perhaps even other websites with which the user has registered the same credentials. For example, an attacker gaining access to the user's credentials could potentially transfer securities or money from the user's brokerage or bank account, and/or purchase products or services via the user's merchant account.
There are many ways for an attacker to fool a user into providing her credentials to an imposter website. For example, an attacker can send out a large number of e-mails inviting the user to logon to a well-known e-commerce website, such as paypal.com, but having a link to the website paypai.com, hoping that the recipient of the e-mail is registered at the financial website paypal.com. The attacker intends to capitalize on the fact that, although the last letter in the link to the imposter website is ‘i’ rather than “I”, this distinction will be overlooked by the user and the user will activate the link. The web pages provided by the imposter website paypai.com are then made to look like those at the real website paypal.com. Thus, the user, viewing the impostor website after activating the link, may have no reason to suspect that the website is not the real paypal.com website. The user may therefore submit the credentials she has registered with the real paypal.com website, e.g. the user's ID and password, to the imposter website in an attempt to login. At this point, the user's credentials are captured by the imposter website. The attacker can then login to the real paypal.com website using the user's ID and password, and authorize or revoke transactions associated with the user's account, potentially even moving money into an account controlled by the attacker.
Thus, not only can the attacker mislead the user into believing that a imposter website is authentic, the attacker can mislead a real website into believing that the attacker is authentic, by using the user's credentials, i.e. the user's user ID and password, to authenticate to the real website, resulting in the real website believing it is dealing with the user when in fact it is dealing with the attacker.
The attacker might alternatively provide the user a link containing what appears on the user's display monitor to be a URL of the real website, e.g. paypal.com, but is in-fact a link to an imposter website. For example, the user may see a link that reads “http://” appended to www.paypal.com.%sdafghdgk% . . . which appears to be a link to the real website paypal.com with a long list of parameters that extend off the end of the URL window in the user's browser. However, unseen by the user, is that this link actually terminates with “ . . . @paypa1.com”. Thus when the user activates the link with a click of the user's mouse, the user is in-fact linked to the imposter website. The imposter website can then operate as above to obtain the user's credentials for the real website.
—Man-In-The-Middle (MITM) Attacks—
Although the use of an imposter website is a common means for an attacker to gain access to a user's user ID and password, these credentials can also be obtained by an attacker launching a man-in-the-middle (MITM) attack. For example, if the user's ID and password are stored on the user's terminal, an attacker may gain access to these credentials, from the user's own terminal. Furthermore, a sophisticated attacker may be able to capture the user's ID and password during the transmission of these credentials to the intended website. In either case, the attacker can then present the user ID and password to a website to successfully authenticate the attacker to that website. This type of attack is also commonly referred to as a form of “phishing”.
True Protection Against MITM and Impostor Website Attacks Using Multifactor Split Key Asymmetric Cryptography
In order to have true protection against phishing, the authentication must be end to end and there must be nothing that an attacker can capture using either an MITM attack or imposter website that can be used by the attacker to demonstrate knowledge of the credentials required to impersonate the real user in subsequent authentications to a real website. Thus, for true protection against phishing attacks, even if the attacker persuades the user to divulge user credentials or otherwise gains access to user credentials, or gains access to the user's network device, the attacker will not be able to reuse the user's credentials or operate the user's device to impersonate the user.
—Armored Credential Systems Using Multi-Factor Split Key Asymmetric Cryptography—
A system has recently been developed which provides true protection against phishing attacks. More particularly, as disclosed in U.S. application Ser. No. 11/055,987, filed Feb. 14, 2005, and entitled “ARCHITECHTURE FOR ASYMMETRIC CRYPTO-KEY STORAGE” [Attorney Docket No. 3001-30], TriCipher, Inc, the assignee of all rights in the present application, has developed an asymmetric cryptosystem in which users are associated with an asymmetric crypto-key pair having a public key and a private key, at least one of which, e.g. the private key, is split into multiple key portions, e.g. multiple private key portions. As in the conventional split key asymmetric cryptosystems discussed above, each of the key portions can be applied to an original message separately or in sequence and the partial results combined to form a transformed, i.e. encrypted, message, and the other key, e.g. the public key, can be applied to the transformed message to verify authenticity of the message preferably by recovering the original message, which authenticates the user. Conversely a message transformed, i.e. encrypted, with the other key, e.g. the public key, can be decrypted by applying each of the split key portions, e.g. the private key portions, to the transformed message separately or in sequence and the partial results combined to decrypt the original message.
However, unlike the other split key asymmetric cryptosystems, the TriCipher system can generate at least one of the multiple key portions of the asymmetric crypto-key using one or more pieces of information, known as factors. For purposes of the following discussion, we will assume that the private key is split and that a first private key portion of the asymmetric crypto-key is generated using the one or more factors. If multiple factors are used, two, three, or even a greater number of factors can be used, as may be desired under the circumstances. In any event, each of the factors is under the control of a single entity. That is, a single entity has possession of, or free access to, each of the one or more factors. The system preferably uses the RSA algorithm and therefore whether three or more keys are used, the system can retain all the desirable security properties of the two key RSA system, while being stronger than conventional two key RSA systems in significant respects.
At the most basic level, sometimes referred to as single armoring, a portion of the split key is computed using only a single factor corresponding to the password. In single armored mode, the user is associated with a password that is input by the user and expanded using an encryption algorithm, preferably one complying with the PKCS5 IETF standard, to generate a factor. Because the password is expanded in accordance with an encryption algorithm to create the factor, the factor is sometime referred to as a ‘hardened password’. In single armored mode the factor itself serves as the applicable portion of the split key. At the next level, sometimes referred to as double armoring, the split key is computed using both the factor corresponding to the password and another factor. At the final level, sometimes referred to as triple armoring, a portion of the split key is computed using the factor corresponding to the password, plus two other factors. In triple armor mode, each user is often associated with a password, and two additional asymmetric crypto-key pairs comprising the two additional factors.
In double armored and triple armored mode, knowledge of the password alone is insufficient for authentication, because additional factors are required for authentication. Furthermore, the authentication is end to end, and there is nothing that an attacker's website can capture which will give the attacker knowledge of all the credentials necessary for authentication because the protocols require the attacker to demonstrate possession of credentials that are not actually transmitted to the imposter website but are required to construct the cryptographic keys used to establish the credentials. Thus, even if the attacker is able to set up a website that looks like the intended website or launch a successful MITM attack, the attacker will at best only be able to obtain and demonstrate possession of the crypto-key credentials, but not the underlying credentials necessary to construct the applicable key, and therefore will not be able to successfully impersonate the user in subsequent authentications. Because of all this, double and triple armored mode can provide true phishing protection.
—One-Time-Password Protection Against MITM and Impostor Website Attacks—
A wide variety of one-time-password (OTP) techniques have been proposed to enhance protection against MITM and impostor website attacks. However, all of the proposed techniques have tended to have (i) a shared-secret between the user and the authenticating entity, (ii) a challenge that both entities agree on, (iii) a response which both entities compute independently using an identical process and the shared-secret, e.g. Process(challenge, shared secret)=>response, with this process having the property that an attacker cannot derive the shared-secret even if the attacker observes several pairs of (challenge, response), and that the challenge varies with each use and is never repeated, (iv) authentication which requires the user to simply type the correct response, i.e. the OTP, say into a web page that is presented on the display of the user's PC and is then transmitted to another entity, such as a sponsor or merchant represented by a server at a website, which in turn communicates the response from the user to the authenticating entity, e.g. a distinguished server, which in turn independently computes the correct response, i.e. the OTP, and if it matches with the response from the user, tells the other entity, e.g. the sponsor or merchant represented by the server at the sponsor or server website, that it is likely the user is authentic.
+Conventional One-Time-Password Techniques+
Exemplary characteristics of four common but different types of OTP techniques are described below.
In time-synchronous type OTP techniques, the shared secret is a large random number, such as a symmetric crypto-key. The challenge is the time at that instant, e.g. the time when authentication is requested. The user has a token, typically a physical device that computes a new response every minute based on Process (shared-secret, time). The technique works by requiring the user to type in the response, i.e. the OTP, currently displayed on the token, which is sent to the relying entity, which is depicted as a system, e.g. the sponsor or merchant server, which has to communicate the received response to the OTP authenticating entity, e.g. a distinguished server, which independently computes the response, and tells the relying entity if the response from the user is correct.
In challenge-response type OTP techniques, the shared secret is a large random number. The challenge is a number the OTP authenticating entity, e.g. the distinguished server, sends the user, preferably directly. The user has a token into which the user types in the challenge sent by the authenticating entity. The token computes a response based on the typed in challenge. The technique works by requiring the user to type in the computed response, i.e. the OTP, and send the computed response to the relying entity, e.g. the sponsor or merchant server, which communicates the received response to the authenticating entity, e.g. the distinguished server, which independently computes a response and tells the relying entity if the response from the user is correct.
In paper-based type OTP techniques, the shared secret is a grid of numbers. The challenge is a set of coordinates for one or more cells in the grid that the authenticating entity, e.g. the distinguished server, sends the user, preferably directly. The user has a paper with the grid of numbers and the authenticating entity also has a copy of the grid. The technique works by requiring the user to type in the numbers in the appropriate cell(s) corresponding to the set of coordinates in the received challenge, and sending the typed in the numbers, i.e. the OTP, as a response to the other entity, e.g. the sponsor or merchant server. The other entity has to communicate the received numbers to the authenticating entity, e.g. the distinguished server, which independently determines the numbers in the appropriate cell(s) corresponding to the set of coordinates from its copy of the grid and tells the other entity if the response is correct.
In OATH and OATH Standard type OTP techniques, the shared secret is again a large random number. The challenge is the value of a counter that is incremented with each use. The user has a token that computes a new response as needed based on Process (shared-secret, counter). The technique works by requiring the user to type in the response currently flashing on token and send the typed in response, i.e. the OTP, to the relying entity, e.g. the sponsor or merchant server. The relying entity communicates the received response to the authenticating entity, e.g. the distinguished server, which independently computes a response and tells the other entity if the response from the user is correct.
On the surface it appears that since the response, i.e. the OTP, changes with each use, that OTPs protect against phishing. However, the phisher does not really care about the password, the phisher wants access to the other entity's website. So the phisher could simply launch a MITM attack which lures the user to a web proxy and then proxy all traffic between the user and the intended website, e.g. the website of a sponsor server or a merchant server.
The phisher can then achieve one of three goals:
If the goal of the phisher is to log into a sponsor or merchant server, the phisher can store the session cookies as they pass through the proxy, copy the stored cookies to the phisher's own network device, e.g. the phisher's PC, and use the stored cookie's to log into a desired server, e.g. a sponsor or merchant server. Observe that this attack requires little sophistication. All that is required of the phisher is the ability to set up a web proxy and copy cookies.
If the goal is to hijack the session, the phisher need only change the proxy website slightly so that the user's ‘logoff’ message does not go through to the intended website, e.g. the website of a sponsor server or a merchant server, and then keep ‘refreshing the session’ to keep the cookies valid. The phisher can then, at leisure, exploit the hijacked session.
If the goal is to pervert certain transactions, for instance to change a user's order for stock ABC to an order for stock XYZ, phisher need only slightly change the proxy website in a different way and the user will dutifully provide the OTP needed to confirm the transaction! An actual attack of exactly this nature was written using a freeware proxy server and a few lines of PERL. And observe that this is completely automated.
Attacks that have already been reported make OTPs useless by themselves as a defense against phishing. To reiterate, such proxy-in-the-middle attacks are extremely simple and will certainly be likely to be used by a phisher targeting a bank or e-commerce site.
The key to preventing such attacks is to use authentication techniques that have the following two properties. First, the authentication technique must not reveal secrets. That is, the “secret” must never leave the user's PC, but rather some “proof” of the secret is sent to the authenticating entity. Second, the “proof” should be such that interference of a MITM will be detected by the authenticating entity, e.g. the distinguished server or the relying party.
Most genuine websites already use server side SSL to authenticate themselves to the user's browser and to set up an encrypted channel. Of course one major reason for phishing is that browser designs did not do a good job of using the server side SSL verification to convey to the user that (i) they are on a SSL-protected site, and (ii) which site they are on. All the browser vendors have already announced plans, and some have already implemented early plans, to improve this situation. Unfortunately this, in and of itself, will not suffice to quell phishing. There are two reasons for this. First, such awareness techniques still require the user to be alert, and in general the user's most likely to be phished are those who tend to be “unconscious and unaware”. Second, most phishers to our knowledge currently do not obtain server side SSL certificates, and rely on the fact that the end user does not notice that they are not at a “protected site”. However, obtaining a ‘server side certificate’ under the name of a company that “sounds like” the genuine company from one of the now very many “trusted” roots browsers ship with, is not likely to thwart a determined phisher.
So while better use of server side SSL certificates is welcome, it does not by itself resolve the issue, and client authentication is needed. In case this is not clear, it should be understood that even with server side SSL certificates it is possible for a phisher who obtains such a fake SSL server certificate to get the user to sign the SSL running hash between the user's browser and the phisher. However, this will be useless to the phisher in signing into the genuine website if client side SSL authentication is also used by the genuine website.
+Proposed One-Time-Password Techniques Using Out-Of-Band Communications+
The use of out-of-band communications has been proposed to enhance protection against MITM attacks in systems relying on one-time-passwords. Here the notion is that by using two separate communications channels, e.g. the browser-server connection via an Internet channel and an SMS cell phone or similar other connection via a telephone network channel, one can thwart a MITM attack because the phisher will find it more difficult to hijack two channels rather than just one channel. While such an approach would enhance protection, it may be attractive to only a narrow class of applications, and therefore lacks broad applicability. Further, while such an approach has the advantage of being ‘non PC invasive’, i.e. no client side software is required and hence it does not require a footprint on the user's network device, it is significantly ‘human invasive’, i.e. the high resistance to installing ‘client software’, which is a one time deployment event, would seem altogether overdone if replaced with a mechanism that creates an constant nuisance for the user over an ongoing period for every authentication.
+Proposed One-Time-Password Techniques Using Legacy PKI+
The use of the legacy two-key public key infrastructure (PKI) has also been proposed as having the capability to enhance protection against MITM attacks in systems relying on one-time-passwords. Legacy PKI, if used correctly, can prevent MITM attacks, and it has been suggested that OTPs can be safely transmitted within a secure channel created using legacy PKI. However, in addition to the other reasons, some of which have been noted above, that legacy PKI has failed to find widespread acceptance and use, even if legacy PKI were implemented in a way in which MITM attacks are prevented, it would remain vulnerable to problems on the back-end integration of the OTPs.
+Proposed One-Time-Password Techniques Using a Password Protection Module (PPM)+
Still another proposal has been offered by RSA Laboratories, the research center of RSA Security Inc. According to the proposal by RSA Labs, every application has an application specific identifier (ASI), e.g. a URL. The browser of the user network device, e.g. the user's PC, catches this identifier, and securely hands it to a password protection module (PPM) which, as understood, is located either outside the user network device operating system or in a very secure part of the operating system. This PPM queries the user for the OTP and hashes it with the ASI. The hash is then handed back by the PPM to the browser of the user network device, which in turn transmits the received hash to a relying entity which is depicted as a system, e.g. a sponsor or distinguished server. The relying entity then transmits the returned hash to the authenticating entity, depicted as a Proprietary RSA server. To validate the returned hash, the authenticating entity must execute proprietary software that independently calculates the hash based on a priori knowledge of the OTP and the ASI. If the hash received from the browser of the user's network device and the calculated hash are a match, then the user is authenticated.
The proposed technique certainly eliminates, at least at this time, the risk of any practical MITM attack, with the exception of a phisher installing software on the user network device that seeks to spoof the “hands it” process identified above. However, the keyword here is “practical”. If the user's browser has the ability to reliably determine the real address, e.g. the real Universal Resource Locator (URL), of the website to which it is submitting the hashed-OTP, in other words if the URL of the MITM is exposed to the browser, and used to construct the hashed-OTP, then the hashed-OTP will be useless and will fail. This is because, if the URL of the MITM is exposed to the user's browser, the MITM will receive the OTP hashed with the MITM website's URL. Thus, if the MITM tries to use this hashed-OTP at the legitimate site, it will be rejected. However, even if at present it is likely that the user's browser will be able to reliably determine the real address of the website to which it is submitting the hashed-OTP, whether or not this will continue to be the case as MITM attacks become ever more sophisticated remains questionable.
On the other hand if the MITM can fool the user's browser into believing that the URL of the MITM website with which the browser is communicating is the URL of the legitimate website to which the browser desires to communicate then the hashed-OTP will be useful at the real site and MITM attack will succeed. This is because, if the URL of the MITM is not exposed to the user's browser, the MITM will receive the OTP hashed with the intended website's URL. Thus, if the MITM uses this hashed-OTP at the legitimate site, it will be accepted.
For example, some of the techniques used in MITM attacks that attempt to grab a raw OTP, i.e. a non-hashed OTP, will typically reveal the URL of the MITM website to the user's browser. These techniques rely on the user not recognizing the rogue URL of the MITM. Other techniques used in MITM attacks tamper with the Domain Name System (DNS) and IP routing infrastructure, and seek to misdirect the user's browser to the MITM website, but with the same URL as the intended legitimate website. So hashed-OTPs will foil some MITM attacks but not others. While the attacks which cannot be foiled using RSA's PPM may be deemed impractical at this time, such attacks are, at least in theory, possible and could become much more likely to be used by phishers in the future. Thus, while the hashed-OTPs used in the proposed RSA PPM will raise the bar, these hashed-OTPs, will not necessarily protect against all MITM attacks.
Furthermore, while the ASI emulates, to some extent, the functionality present in SSL to prevent man in the middle, it cannot fully protect against all types of MITM attacks. Furthermore, while the protected area on the user's network device is certainly something that any mechanism can take advantage of, why RSA's proposed PPM should do hashing of the OTP instead of digital signing is not clear. Further still, the RSA PPM requires added instructions on the user network device, i.e. requires a footprint on the user network device, which puts it on par with any other solutions that thereby tend to be unacceptable to users and/or sponsors. Indeed, the technique requires fundamental changes to the commercially available web browser commonly installed on today's user network devices. Additionally, the technique also requires changes to the authenticating entity network station. Additionally, the proposed RSA PPM does nothing about addressing the back-end risk of password files being stolen or the theft of OTP secrets from insecure software. Although such back-end attacks are rarer than garden variety phishing, they are catastrophic when they are successful because all user credentials are compromised. Finally, since the proposed RSA PPM requires that the hash be different for each application, e.g. one hash is used to access the user's brokerage account and a different hash is used to access the user's bank account, the PPM makes single sign-on more difficult.
In summary, hashing a OTP using the PPM proposed by RSA Labs, requires the execution of a new proprietary browser interface on the user's network device, e.g. a user's PC, and therefore requires a change to existing browser standards, such as CAPI/PKCS11. The RSA proposal also requires the execution of new proprietary software by the authenticating entity station, e.g. a sponsor or distinguished entity server, rather then utilizing existing SSL software. The proposed system is also subject to catastrophic back end risks, and requires a change in the conventional OTP processing in order to hash the OTP with an ASI.
+Proposed One-Time-Password Techniques Using a Protected OTPs+
To address deficiencies in the RSA Labs' proposed OTP hashing technique using a PPM and the other proposed enhancements to conventional OTP techniques, the above-identified related application discloses a one-time-password authentication technique with enhanced protection against MITM attacks. The application describes a technique in which a secure communication tunnel is established between the authenticating entity and the user for communication of the OTP. Using this technique, a user of a communications network, such as the Internet or other network, can be securely authenticated based on a one-time-password (OTP).
The technique utilizes a user's associated private/public asymmetric crypto-key pair d, e, which could be an RSA or some other type asymmetric crypto-key pair, to secure the communication of the OTP. More particularly, in one exemplary implementation the user's private key d is split into a first private key portion d1 and a second private key portion d2. The user partially signs a symmetric session key K with the first private key portion d1 to form a first message M1, i.e. M1=sign [K, d1]. The authenticating entity receives the partially signed symmetric session key in message M1 from the user via the network. The authenticating entity completes the signature on the received partially signed symmetric session key with the second private key portion d2 to recover the symmetric session key, i.e. sign [M1, d2]=K. It will be understood that completion of a signature may also require the application of the public key e, if the public key e was not applied by the user in forming the partial signature. Furthermore, completion of a signature could additionally require the application of the other portions of the private key d, if the private key is split into more than portions d1 and d2, and any other such portion was not applied in forming the partial signature.
The user encrypts a OTP with the symmetric session key to form a second message M2, which is sometimes referred to as a protected one-time-password (POTP), i.e. M2=POTP=encrypt [OTP,K]. Stated another way, a protected secure tunnel for communicating the OTP is established by encrypting the OTP with the symmetric session key. The authenticating entity receives the message M2 with the encrypted OTP, from the user via the network, i.e. receives the OTP via the secure tunnel, and decrypts the received encrypted OTP with the recovered symmetric session key, i.e. decrypt [M2,K]=OTP. The user is then authenticated based on the decrypted OTP.
The user can also be authenticated based on the recovery of the symmetric session key by the authenticating entity. If so, there will be multiple levels of user authentication. That is, at one level the user is authenticated by proving knowledge of the private key portion d1, i.e. knowledge of the user portion of the split private key, while at another level the user is authenticated by proving knowledge of the OTP. The authenticating entity can also partially sign the recovered symmetric session key with the second private key portion d2 to form a third message M3, which is received by the user from the authenticating entity via the network, M3=sign [K,d2]. In such a case, the user can complete the signature on the received partially signed symmetric session key in message M3 with the first private key portion d1 to recover the symmetric session key, and authenticate the authenticating entity based on the recovery of the symmetric session key, i.e. sign [M3, d2]=K.
Typically, only after the user is authenticated based on the decrypted OTP, will the authenticating entity partially sign a relying party authenticating message (RPAM) with the second private key portion d2, i.e. the authenticating entity portion of the split private key, to form an partially signed authentication message (PSAM), i.e. PSAM=sign [RPAM, d2]. The RPAM is the message sought by the relying party, e.g. a merchant, to prove to the relying party that this is in fact the user and not an imposter. The RPAM could, for example, take the form of a secure socket layer (SSL) hash, e.g. client side SSL hash of prior messages communicated between the user and the relying party. The user receives the partially signed RPAM in message PSAM from the authenticating entity, e.g. a sponsor or distinguished entity, via the network. The user further signs the received partially signed relying party authenticating message with the first private key portion d1, which as previously noted is the user portion of the split private key, and transmits a further signed authenticating message (FSAM), with the further signed RPAM to the relying party via the network, i.e. FSAM=sign [PSAM, d1]. The RPAM is recoverable by the relying party by applying the public key e to the FSAM, i.e. sign [FSAM,e]=RPAM. Hence, the relying party can recover the relying party authenticating message RPAM with the user's public key in order to confirm that the user has been authenticated by the trusted authenticating entity.
The Continued Threat from Phishers, Pharmers, Browser Malware, Browser Trojan Horses and the Like
While the techniques described above can be used to provide enhanced authentication security, attackers continue to develop new and more sophisticated attacks. More recently, there has been increased concern relating to pharming attacks and other types of attacks that may result in domain name system (DNS) poisoning.
While in phishing attacks the attacker will send an email that appears to come from a well known, trustworthy website, in order to convince the user to go to the imposter site and enter personal, financial or other sensitive information that the perpetrators can exploit for personal gain. On the other hand, in pharming the attacker installs malicious code, sometimes referred to as malware, or Trojan horses, on a PC or server, which will misdirect the unsuspecting Internet user to a fraudulent website, which then ask the user to enter personal, financial or other sensitive information (see for example, “Hackers get to the root of the problem” by Dan Geer. IEEE Computer, May 2006, Page(s): 17-19). The pharming results in DNS poisoning. That is, while the URL being displayed in by the browser window on the user's network device appears to be perfectly proper, unbeknownst to the user, the displayed URL is mapped to fraudulent website's Internet Protocol (IP) address. This results in the unsuspecting Internet user being misdirected to the fraudulent website, which then asks the user to enter personal, financial or other sensitive information.
There can be little doubt that network communications will, in the future, be subject to still other types of attacks and attackers, which are not now even being contemplated.
Accordingly, there remains a need for further enhanced security for communications over a network, in order to protect against attacks, such as those launched by phishers and pharmers, browser malware, Trojan horses, domain name poisoning and the like.